Qualify Customer for Loyalty Tier Based on Purchase

This use case describes the workflow of qualifying a customer for a new loyalty tier when they make a purchase. Once the purchase is made, SessionM determines if it generates enough points to satisfy the purchase behavior ruleset that governs how point-based outcomes are awarded.

Part of configuring a SessionM implementation is the definition of a point economy, which provides the foundation for points-based loyalty programs. The key components of a point economy are point accounts, along with policies that define how points are redeemed and expired. With a point economy configured, a client can then define a tiered loyalty program, which can offer rewards based on purchases. The tiers within the loyalty program allow the client to offer different levels of rewards to its customers, each with benefits that recognize a customer's history of spending and brand engagement.

The provisioning of points to point accounts can happen several ways:

  • Awarded through a campaign.

  • Awarded as an outcome of a transaction or event.

  • Deposited by a customer service representative adding points manually.

This use case features a points-based outcome based on a customer's purchase transaction.

Customer Journey

One helpful way of understanding this use case is to consider how it reflects the customer's experience, or journey, in the "real world."

Customer spends $10 to buy coffee and scone at local cafe

POS system sends transaction on to SessionM for evaluation against tier ruleset

10 points are added to the customer's point account if purchase meets ruleset criteria

Customer is then promoted to new tier if point account total qualifies for tier change

Current loyalty tier status displayed for customer

Platform Configuration

Before implementing this use case, ensure the following have been configured:

Points

Points account created in environment.

Economies

Point economy with at least two tiers set up, configured with the following behaviors for each tier:

  • Entrance behavior - Set amount of points and limit to particular point account for entering tier.
  • Purchase behavior - Award points per dollar to point account in order to allocate points per purchase.
  • Maintenance behavior - Set to run at regular interval to ensure tier members can remain in tier.

Sequence Diagram

See the overall flow for this use case below.

CUSTOMER CUSTOMER POINT OF SALE POINT OF SALE SESSIONM SESSIONM QUALIFY CUSTOMER FOR LOYALTY TIER BASED ON PURCHASE 1 Visit retail location and Purchase item 2 Send or create  transaction using SessionM user_id 3 Enqueue transaction job 4 Add points to point account based on tier rule sets 5 Move customer to new tier if enough points earned 6 Return 200 level message for successful transaction 7 Request  current tier level status for customer 8 Return current tier level status for customer 9 Display current tier level status to customer

Alternative Path

In the diagram above, step 4 adds points to the customer's account based on logic configured in the tier rule set that triggers an award of points when a purchase is made. But another option is to sidestep such logic and simply deposit points into the account directly using this endpoint, detailed in the UserPoints API documentation: POST /api/1.0/user_points/deposit.

In addition, consider step 7, which makes a request for the customer's tier level status using the UserTiers API (Incentives domain package). This information, however, can also be obtained using the Standard Profile API (for basic tier in primary system) or the Custom Profile API (for tiers in all systems). These operations are detailed in the task, Get Customer Profile. Note that if you use the endpoint to retrieve the combined profile (standard/custom) in order to see data for all tiers and systems, you'll need to set the additional parameters detailed in the "API Endpoint Constraints" section of the Get Customer Profile task article.

Best Practices

Consider setting limits on earning frequencies.

Consider using rolling point expiration policies to govern the point accounts.

With respect to tier maintenance:

  • Can take several days to run.

  • Drops customers from one tier to a lower tier. Tier level of a customer drops only when tier maintenance is run.

  • Other behaviors and associated outcomes may be scheduled to run at the same time maintenance processes are set up to run. This overlap of having two or more behaviors working on the same data at the same time may cause unexpected results. Best to avoid potential race conditions during maintenance.

When ranking outcomes designated for behaviors, bear in mind that the rank controls when the outcome starts. When rankings control a subsequent outcome, it runs after the previous, higher-ranked outcome begins, not after the previous outcome finishes.